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A high-level review was conducted to provide an analysis of the existing archi- 
tecture used to handle data and implement control algorithms for NASA’s Deep 
Space Network (DSN) antennas and to make system-level recommendations for im- 
proving this architecture so that the DSN ante /211 as can support the ever-tightening 
requirements of the next decade and beyond. It was found that the existing sys- 
tem is seriously overloaded , with processor utilization approaching 100 percent. A 
number of factors contribute to this overloading , including dated hardware, ineffi- 
cient software, and a message-passing strategy that depends on serial connections 
between machines. At the same time, the system has shortcomings and idiosyn- 
crasies that require extensive human intervention. A custom operating system ker- 
nel and an obscure programming language exacerbate the problems and should be 
modernized. A new architecture is presented that addresses these and other issues. 
Key features of the new architecture include a simplified message passing hierarchy 
that utilizes a high-speed local area network, redesign of particular processing func- 
tion algorithms, consolidation of functions , and implementation of the architecture 
m modern hardware and software using mainstream computer languages and oper- 
ating systems. The system would also allow incremental hardware improvements 
as better and faster hardware for such systems becomes available, and costs could 
potentially be low enough that redundancy would be provided economically. Such a 
system could support DSN requirements for the foreseeable future, though thorough 
consideration must be given to hard computational requirements, porting existing 
software functionality to the new system, and issues of fault tolerance and recovery. 


I. Introduction 

The objective of this study was to provide an indepen- 
dent assessment of the capabilities of the current antenna 
control system data handling assemblies and to make rec- 


ommendations for future subsystem development to be 
used as a guide during planned upgrades in the 1992 to 
1995 time frame. The study focused on the data handling 
architecture of the antenna control system as it exists in 
the field and on its ability to handle the task of provid- 
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ing operator monitoring and control of the system. The 
system is built upon an elaborate message processing and 
transmission protocol that clearly shows the impact of ad- 
hoc system evolution in the form of late and lost messages. 
The study addresses the handling of the monitor and con- 
trol data messages and the suitability of the design to sus- 
tain adequate message handling services. 

The specific algorithms of the antenna control system 
have been reviewed, and a number were identified as hav- 
ing the potential to significantly impact the ability of the 
system to maintain timely responses. These algorithms in- 
clude predict processing, correction for systematic errors, 
automatic boresighting correction, display generation, and 
collection of monitor data. Where alternate algorithms 
that require fewer system resources can be identified, these 
have been incorporated into the assessment and recom- 
mendations. Furthermore, although few criticisms have 
been levied against the lowest level servo-loop algorithms, 
it would be prudent to allocate increased system resources 
to them in order to support the evolution that should be 
possible in a healthy system with margin for growth. 

The study was not constrained by implementation con- 
siderations associated with transition to a new system, 
system outages, and planned maintenance periods. These 
considerations are, however, real limitations on any up- 
grade plan, and, although they have not been addressed 
specifically, these issues have been reflected implicitly in 
the proposed data handling architecture in that the num- 
ber of proposed changes to the system is minimized. 


II. Overview of the Current Architecture 

Each antenna at a given site includes its own antenna 
control system. The Control Monitor Console (CMC) op- 
erator builds a link consisting of a Link Monitor Console 
(LMC), the Antenna Pointing Assembly (APA), and an 
antenna to enable communications with a spacecraft or 
for radio astronomy. Each APA is time-shared among up 
to three links. Because of the critical role of the APA in 
the link, a second APA is held in reserve as a backup, and 
can be automatically switched into action in case of fail- 
ure. The control system architecture is defined as the sum 
of the subsystem functions, their assignment to hardwaie 
elements, and the resulting topology (Fig. 1). The an- 
tenna physical interfaces are not shown, but they consist of 
angle encoders, gimbal motor rate commands, and safety 
interconnect logic connected to the Antenna Servo Con- 
troller (ASC), Antenna Control and Monitor (ACM), Mas- 
ter Equatorial Controller (MEC), and Subreflector Con- 
troller (SRC). 


The principal functions of the antenna control system 
consist of antenna pointing control, antenna performance 
monitoring, and maintenance support and fault isolation. 1 
Partitioning these functions into subunits begins with the 
APA, which receives and processes directives addressed to 
the control system. The major APA functions include 2 

(1) Processing predicts. The APA receives predicts from 
the LMC specifying antenna attitude and corre- 
sponding time at coarsely spaced intervals. The pre- 
dicts are interpolated in time and coordinate trans- 
formed. 

(2) Performing automatic boresight correction (Conical 
Scan [CONSCAN]). Receiver automatic gain control 
(ACC) data are collected over a 30-sec period and 
processed using a fast Fourier transform algorithm. 

(3) Monitoring status for performance and safety and 
providing operator displays. 

The Antenna Control Subassembly (ACS), one of which 
is dedicated to each antenna, is assigned to an APA by 
the CMC for a given link. The ACS must be capable of 
operating successfully even during a switch from one APA 
to an alternative or a change in the controlling CMC. The 
major functions of the ACS include 3 

(1) Pointing the antenna as directed by the APA. The 
predicts are refined, more coordinate transforma- 
tions are applied, and systematic error corrections 
are added. 

(2) Participating in automatic boresight pointing by 
providing pointing angles to the APA and execut- 
ing scan-drive pointing commands. 

(3) Monitoring and configuring antenna equipment. 

(4) Processing systematic error corrections. The ACS 
incorporates site-dependent systematic error correc- 
tions into the predicts. These corrections are used 
to offset biases introduced by gravity sag, atmo- 
spheric refraction, encoder bias, and axis misalign- 
ments. The systematic error correction tables are 
prepared off-line by the antenna engineer and stored 
with other configuration data in the LMC. 

The ASC, MEC, and SRC control servo loops are sim- 
ilar to one another when viewed at the functional level. 


1 DSN System Functional Requirements Document &20-20 Rev ♦ A, 
General Requirements and Policies Through tOi>$ } JPL D-5081, 
vol . 1, change 3 (internal document), Jet Propulsion Laboratory, 
Pasadena, California, pp. 3-5, June 15, 19S0. 

2 Op. cit., p. 3C-3. 

3 Op. cit., p. 3C-8. 
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On those antennas with an MEC, the ACS sends pointing 
commands to the MEC and the ASC is slaved to follow, 
with error signals originating from an autocollimator. The 
ACS provides corrected pointing predicts to the MEC and 
to the ASC as backup information, but corrects each pre- 
dict using systematic error tables for the individual con- 
troller. In the event of a failure or loss of lock in the MEC, 
the ASC drops back to executing pointing commands from 
the ACS. At a high level, the servo-loop controllers per- 
form the following functions: 

(1) Executing the antenna pointing commands via a 
servo control loop. 

(2) Monitoring and reporting the status of equipment. 

III. Analysis of the Current Architecture 

Prior to any explanation of the problems that prompted 
the current study, it should be clearly understood that the 
system is currently fulfilling its intended role. Taken as a 
whole, the Mark IVA is a complex system that has served 
admirably for some 6 years. Improvements and fixes have 
been applied over this time in a layered fashion, and ex- 
pectations have changed because of advances in technology 
and improved understanding of the practical requirements 
based upon experience. Nevertheless, there are anomalies 
on record, functions that are inoperable, and a pervasive 
sense among the operators that the control system gradu- 
ally grinds to a halt during heavy loading after a few hours 
of use. 

Well-defined symptoms of problems have been ob- 
served. Operators have experienced slow update rates for 
critical display information, lost messages, and floods of 
warnings that ultimately originate from a single event. 
This combination of problems has two effects. First, the 
congestion in the communications channels is aggravated, 
possibly causing interference with other functions. Second, 
the operator’s ability to respond correctly and in a timely 
fashion to an event is impaired, because of the time de- 
lays associated with critical messages and the distraction 
caused by a flood of messages. Currently, each subsystem 
generates its own set of messages for the operator when 
problems are identified. Although problems are rated on 
an urgency scale from one to five, causality is difficult to 
trace. Thus, messages tend to proliferate through the sys- 
tem. One result of this is that the APA processor duty 
cycle has been observed at close to 100 percent. 4 Though 
an upgrade to a new, higher capacity processor for the 

4 R- D- Rasmussen and N. T. Brady, Mark IVA Antenna Control 
System Data Handling Study Final Report (internal document), 
Jet Propulsion Laboratory, Pasadena, California, February 9, 1990. 


APA has already been approved, such an approach treats 
the symptom of the problem rather than the root cause, 
which lies in the system connectivity and functional allo- 
cations. 

Many of the anomalies are related to new requirements 
or unmet expectations. For example, the antenna and sub- 
reflector positions are not logged, and the displays gener- 
ated by the system are not as useful as they might be. The 
changes required to correct these anomalies can be ade- 
quately negotiated and implemented in the future, just as 
the many other changes to the system have been performed 
over the past years. Only a few of these reported anomalies 
reflect the system inadequacies that are the subject of this 
study. The system change process does draw attention, 
however, to a principal shortcoming of the system reflected 
in the lack of reserve Central Processing Unit (CPU) ca- 
pacity to easily execute software repair and improvement. 
Furthermore, some algorithms and practices (e.g., CON- 
SCAN) consume resources inefficiently, although they do 
not appear to have a major impact on the system perfor- 
mance. On the whole, the functional design of the system 
is adequate, given the original requirements and the use of 
the system as it has evolved. 

Within the scope of this study there are several iden- 
tifiable features of this architecture that impact the per- 
formance of the system. These features are candidates for 
change in a modified architecture: 

(1) The message* passing system needs improvement. A 
significant portion of the observed behavior of the 
system is tied to message passing response, since any 
message or command originating at the LMC must 
pass through several subsystems prior to reaching 
its addressee. Most of these intermediaries perform 
some processing of the message, either translating or 
expanding its contents. This multi-level hierarchi- 
cal message passing system results in significantly 
delayed information when any subsystem is highly 
loaded. 

(2) The control subsystems were implemented in com- 
puter hardware that, while current for the time, is 
significantly outdated by current standards. The hi- 
erarchical partitioning of the system may in fact be 
a derivative of the limitations of the then-current 
hardware. An alternative architecture built upon 
more capable hardware would place major functions 
entirely within one subsystem. 

(3) The communication channels slow the performance 
of the system, given the basis in message passing and 
the hierarchical topology of the system. 
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(4) The existing hardware topology constrains the po- 
tential functional topology options. The physical se- 
rial communications lines severely restrict the possi- 
bility of reallocating functions or repartitioning mes- 
sage paths. 

(5) Logging and archiving of monitor statistics are not 
performed in a systematic manner. Typically, the 
operators disable the monitor data logging function 
because it slows down the system. 

As a result of the existing multilevel architecture, de- 
tailed knowledge of the antenna subsystem is embedded 
in several subsystem elements. The operator is forced to 
know detailed, low-level start-up, operation, and fault iso- 
lation sequences. Hardware-specific errors are reported by 
every system. Operability and maintainability of the sys- 
tem would be substantially improved if each antenna sub- 
system received higher level commands and reported sum- 
mary error conditions in a condensed, predigested format. 
Ideally, the operator might, for example, command initi- 
ation of a track for a specific spacecraft, and the antenna 
control subsystem would configure, point, and monitor au- 
tomatically, based upon preconfigured tables and supervi- 
sory functions. While the antenna control proceeds auto- 
matically, a monitor function associated with the antenna 
would collect exceptions, filter and process messages, and 
provide critical advisories to the operator. 

IV. Specific Recommendations 

A. Predict Processing 

Predict processing is a core function of the system and 
provides the directives for pointing the antenna control 
system. The system’s communication and computation 
burdens would be significantly reduced if a single interpo- 
lation algorithm were used by the servo controller. Fur- 
ther reduction in computation could be achieved by using 
a single coordinate system for all predicts and delaying the 
conversion to the antenna-peculiar coordinate system until 
the predicts reach the servo controller. 

Implementing these changes would reduce computa- 
tions, memory and disk storage requirements, and commu- 
nication channel message volumes. The algorithms appear 
to be well within the capability of current hardware. This 
amounts to the replacement of extensive tabular data with 
an on-demand generator function. 

B. Application of Systematic Error Corrections 

The predicted pointing angles are corrected in the ACS 
for such systematic errors as gravity sag and atmospheric 


refraction. Application of these corrections is not compu- 
tationally intensive, since it involves combinations of table 
entries and simple interpolations. The only change rec- 
ommended is to provide automatic selection of the proper 
tables without operator intervention, given the operational 
mode. 

C. Generation of Systematic Error Correction 
Functions 

Determination of the proper systematic corrections is 
severely hampered with the current method of data mon- 
itoring. Logging should be reinstated, and the systematic 
error modeling and creation of the correction tables should 
continue to be done off-line. The antenna engineer should 
be supported with investigative access to the antenna, per- 
haps under the maintenance mode, to assist in identifying 
error mechanisms and parameters. The Program Office 
should continue to invest in the development of on-line 
error-tracking and system calibration capabilities. Future 
enhancements might include the incorporation of real-time 
calibration and error tracking. 

D. Generation of Operator Displays 

Data for inclusion in displays are generated at all levels 
of the control system, and most of the displays themselves 
are generated in the APA. In general, displays should not 
be generated by any element of the antenna control sys- 
tem that must also execute a real-time control function 
such as CONSCAN, servo loops, or exception monitoring. 
The operator console or a new unit in the antenna control 
system should be used to build the displays directly from 
a new database without recurring inquiries acted upon by 
the servo-loop systems. This implies an attendant change 
from generation of data on demand to a policy of maintain- 
ing a database of status information. Monitor and display 
data should be passed in a compact, binary mode using 
agreed-upon data structures. 

E. Single Point Antenna Monitor and Control 

The monitor and control functions contained in the cur- 
rent functional architecture of the antenna control system 
should be collected and utilized as a single point of repre- 
sentation for the antenna. The intent is to partition low- 
level knowledge of the configuration and error handling to 
functions within the antenna, leaving the LMC operator 
with a consolidated, high-level interface. This function, 
named herein the “antenna monitor and control function,” 
is not significantly different from the original design role of 
the ACM subsystem. However, the ACM as presently im- 
plemented is too close to the mechanical interfaces of the 
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antenna hardware and, except for the watchdog activity, 
executes little monitoring and no control. 

Several implementation issues support the reinstate- 
ment of an effective monitor and control function besides 
raising the level of the operator interface. An interface be- 
tween the control room Local Area Network (LAN) and 
the antenna network is required to minimize undesired 
message traffic, buffer signals for the potentially long dis- 
tance to the antenna, and allow for media differences be- 
tween the two network domains. Thus, a computer system 
that hosts the monitor and control function that is located 
in the control room can serve as the internetwork gateway 
and electronic interface. 

V. Proposed Architecture 

A. Functional Architecture 

To alleviate the observed performance problems of the 
current system, modifications to the architecture could 
incorporate one or more of the following (the top-level 
system diagram that incorporates these modifications is 
shown in Fig. 2): 

(1) A simplified message-passing hierarchy where the 
path from any sender to any receiver includes at 
most one, and preferably no, intermediate subsys- 
tems or logical tasks. The intention is to reduce 
message passing delays; when accompanied by con- 
solidation of tasks within more powerful servo con- 
trollers, this can be readily accomplished. 

(2) Implementation of a network local to the antenna- 
control system that eliminates the point-to-point 
low-speed communication channels. This would es- 
tablish each subsystem as a peer on the network and 
provide the physical mechanism to support direct 
addressing of all messages. Most reasonable net- 
work implementations will also provide reliable com- 
munications at substantially higher speeds than the 
present RS-232 protocol. Careful consideration must 
be given to the distance requirements, which, for 
some antennas, might reach 10 km from the control 
room to the antenna. Again, most reasonable net- 
work implementations can meet this requirement, al- 
though careful design is required, and slightly higher 
costs can be expected for the long-distance segments 
of the network. 

(3) Redesign of certain functions to reduce the com- 
putation, storage, and message volume associated 
with the algorithms. Specifically, predict process- 
ing might employ a single coordinate system and a 
single interpolation algorithm. 


(4) Consolidation of antenna monitor and control func- 
tions and implementation in a system that resides at 
the interface between the control room network and 
the antenna network. 

(5) Utilization of new, modern 32-bit commercial com- 
puter hardware with a Teal-time operating system 
kernel and network-based communications. This 
would provide significant flexibility in the design of 
the new architecture task structure and provide a 
basis for potential incorporation of fault tolerance 
through semiautomatic reconfiguration. The princi- 
pal motivation for this change is to provide increased 
processing power and high-speed, standardized com- 
munications at relatively low cost. 

The system functions would be retained and allocated 
to the logical units of the modified architecture. The prin- 
cipal differences are 

(1) CONSCAN, or automatic boresighting, is executed 
entirely within the servo controller. 

(2) Systematic errors are corrected at the servo con- 
troller. 

(3) The monitor and control function oversees operation 
of the antenna subsystem and maintains a database 
that is used to generate displays for the LMC. 

B. Principal Features of the Modified Architecture 

The topology of the modified architecture represents 
a simpler hierarchy by replacing the APA and ACS with 
a single unit that is logically a part of the antenna con- 
trol system and provides a network interface and high- 
level monitor and control functions. Elimination of the 
functions currently allocated to the APA and ACS is not 
proposed. All existing functions should be retained, al- 
though a few should be reformulated and hosted in new 7 
subsystems. 

The antenna control subsystems are depicted as peers 
on a local network. This network might be implemented 
in several ways, for example, in Ethernet between separate 
computers or in shared memory among multiple processors 
on one common backplane. Such a network should support 
a virtual communications system defined in software, as 
might be done wdth Unix sockets or Transmission Control 
Protocol/Internet Protocol (TCP/IP) channels, and would 
provide reliable, high-speed communications at very low 
cost. 

The architecture retains the MEC and SRC units, prin- 
cipally as logical functions. It might be entirely possible 
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to host these less intensive functions as tasks on the same 
CPU with the ASC. Hardware such as an MC68040 on 
the VMEbus or an 180486 on the Multibus II provide suf- 
ficient capacity to execute the current functions and servo 
loops. Economical systems with either Ethernet or back- 
plane networks are readily available. 

An additional subsystem, the Antenna Monitor and 
Control (AMC), has been included in the architecture to 
provide a high-level interface to configure and control the 
antenna and to monitor the status of the antenna system. 
The AMC provides local access for maintenance, moni- 
toring, or calibration, and provides data collection, analy- 
sis, and monitoring for identification of systematic errors, 
equipment failures, or anomalies in support of reconfigu- 
ration, and potentially even intelligent real-time oversight 
of operational status. These functions are probably quite 
similar to the original intent of the ACM, although the 
ACM as it has evolved is too intimately associated with 
the physical interfaces to the antenna to also host higher 
level functions and network connection needs. 

The AMC takes on the display generation functions cur- 
rently resident within the APA. Routine monitor data are 
collected and stored in the database within the AMC and 
utilized to generate displays as required by the operator. 
All high-level operator commands are expanded and sent 
directly to the subsystem that hosts the targeted task. For 
example, predicts and interpolation parameters are mes- 
saged directly to the pointing task resident on the ASC 
where the servo loop performs the interpolation and cor- 
rection when required. 


VI. Implementation Options 

Beyond the recommendation to rebuild the system in 
modern commercial software and hardware, several imple- 
mentation and configuration options are available. The 
commercial market is well developed, with excellent prod- 
uct selection and price competition. A good development 
environment based upon Computer Aided Software En- 
gineering (CASE) tools for real-time systems should be 
utilized and the control software rewritten based upon a 
real-time kernel. Where possible, the existing IIAL-S and 
PL/M code should be converted to a current language that 
can be supported by the CASE tools and available pro- 
grammers. 

In the hardware arena, configuration options for the 
computers that host the antenna control system functions 
range from replicating the current configuration, which is 


one CPU per chassis per subsystem, to one chassis with 
a few CPUs hosting all functions. Within this implemen- 
tation framework, several development options exist that 
can contribute to improved reliability and the incorpora- 
tion of fault tolerance. The necessity of such improvements 
depends entirely on the yet-to-be-developed detailed reli- 
ability requirements. 


VII. Summary and Recommendations 

This study focused on the architecture of the antenna 
control system and its ability to handle the task of pro- 
viding operator monitoring and control of the system as it 
has evolved and exists in the field. Recommendations for 
modifications to the existing architecture have been pro- 
posed and further investigation and design in key areas is 
required prior to final planning for the system upgrade. 
This section briefly summarizes these areas. 

Detailed assembly-level requirements must be derived 
for such functions as error reporting, operator control of 
lower level devices, and status presentations. The system 
documentation consistently neglects the development of 
coherent propagation of requirements to the lower levels 
of the servo controllers. 

With derived requirements in hand, the modified archi- 
tecture design can be continued. The immediate need is 
for a budgetary cost estimate for the upgrade. This can be 
obtained once CPU loads, communication channel capac- 
ities, and memory sizes are estimated from the functional 
descriptions and requirements. Since the system’s overall 
costs are not very sensitive to the exact number of Single 
Board Computers (SBCs), attention should be directed to 
firming up the architecture configuration. 

Considerable attention is required in the area of specify- 
ing the reliability requirements for the system to the level 
of detail that permits selection of a particular method. 
The current central requirement based upon a guaranteed 
no t-to-exceed downtime is insufficient. Other derived re- 
quirements in the form of probability of failure, fail-safe 
or fail-tolerant design paradigm, or worst case failure are 
required to enable a design choice among such reliabil- 
ity enhancements as voting, hot spares, and fault-tolerant 
subsystems. 

Development of an on-line error tracking and system 
calibration capability needs to be done first so that re- 
quirements can be integrated into the planned upgrade. 
Most probably, a development period of several years 
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will be required and installation in the antenna systems 
might occur after the upgrade period. With an early start 
on the development, capacity might be installed to accept 
later deliveries, or at least the system can incorporate the 
necessary “hooks” and access ports for eventual installa- 
tion. 


There are significant constraints associated with main- 
taining system services during the modification period that 
were excluded from the current study. Several means to 
achieve a phased, testable installation exist, and the ram- 
ifications and details would be worked out in the develop- 
ment plan. 















